r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

⚠️ Warning ⚠️

• The following commits have merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged.

  • fc00f6e

  You can start a rebase with the following commands:

  $ # rebase
  $ git pull --rebase https://github.com/rust-lang/rust.git master
  $ git push --force-with-lease
  

If the src/bootstrap directory is missing (for example, when running
x.py from an unexpected location), the script now exits with a clear,
actionable message instead of failing with a less informative traceback.

If you run x.py from a different location, it will still be able to locate src/bootstrap. x.py looks relative to it's own location.

The import bootstrap statement is now wrapped in a try/except block to
provide a friendlier message if the module cannot be imported.

I don't see the point in this. This error can't happen unless you changed any of the python code. And if you do, the builtin python exception message is fine.

The stacklevel for Python version warnings has been changed from 1 to 2,
ensuring that the warning message correctly points to the user's invocation
rather than an internal line within the script.

What user invocation? Can you show the warning that would be printed before and after this PR?

Thanks for the feedback!

If you run x.py from a different location, it will still be able to locate src/bootstrap.

You're absolutely right — I verified that x.py already resolves src/bootstrap relative to its own location, so this extra existence check doesn't add value. I can remove that part.

The import bootstrap statement is now wrapped in a try/except block to provide a friendlier message if the module cannot be imported.

Good point. I agree that this situation would only happen if the bootstrap code itself is broken, in which case Python’s native traceback is indeed clearer. I’ll revert that change as well.

The stacklevel for Python version warnings has been changed from 1 to 2... What user invocation?

Sure! Here’s an example of the difference.

Before (stacklevel=1):

/path/to/rust/x.py:53: UserWarning: Using python 3.5 but >= 3.6 is recommended.
  warnings.warn(msg, stacklevel=1)

After (stacklevel=2):

UserWarning: Using python 3.5 but >= 3.6 is recommended.

The goal was to remove the internal file reference (x.py line number) so that the warning appears cleaner to users running the script. That said, this is minor — I can drop this change too if it’s considered unnecessary.

If maintainers prefer keeping x.py minimal, I’m happy to simplify this PR to just the improved warning text (without changing stacklevel or import behavior).

I don't feel like we want to land this, the current error handling is sufficient and these changes don't address any real problem as far as I see

Thanks for the feedback! I understand this doesn't address a critical need.
I'll close this PR. Appreciate you taking the time to review!

In any case, I see this is your pull request, thanks for trying to contribute!

A good place to start is by looking through issues with labels like C-cleanup, E-needs-test, E-needs-bisection, and A-diagnostics, these are often great first issues for new contributors